Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/rdisc/rdisc-minutes-89dec.txt

Internet Message Format | 1993-02-17 | 11.7 KB

Return-Path:
Received: from pescadero.stanford.edu by NRI.NRI.Reston.VA.US id aa09367;
          6 Jan 90 18:43 EST
Received:  by Pescadero.Stanford.EDU (5.59/25-eef) id AA08497; Sat, 6 Jan 90 15:45:16 PDT
Date: 6 Jan 1990 15:30-PST
From: Steve Deering <[e-mail]>
Subject: Router Discovery WG meeting report
To: [e-mail], [e-mail]
Message-Id: <90/01/06 [e-mail]>

Greg and Phill,

Here are the minutes of the first meeting of the Router Discovery WG,
for you to file away.  Note that the minutes refer to "gateway" discovery,
rather than "router" discovery, which was our terminology at that time.

Steve

--------------------------------------------------------------------
Gateway Discovery Working Group
Chairperson: Steve Deering/Stanford

REPORT ON MEETING OF DECEMBER 12, 1989
at DEC Western Research Lab, Palo Alto, CA.
Reported by Steve Deering

ATTENDEES

1. Art Berggreen    [e-mail]
2. Noel Chiappa *    [e-mail]
3. Farokh Deboo        sun!iruucp!ntrlink!fjd
4. Steve Deering    [e-mail]
5. Richard Fox        sytek![e-mail]
6. Keith McCloghrie    sytek![e-mail]
7. Jeff Mogul        [e-mail]
8. Stephanie Price    cmcvax![e-mail]
9. Greg Satz        [e-mail]

* Noel Chiappa attended by speaker phone.

MINUTES

This was the first meeting of the Gateway Discovery Working Group,
although it has been very active by email since it was formed on
October 27, 1989.  The meeting was held back-to-back with the first
MTU Discovery Working Group meeting.  Our thanks to Jeff Mogul and
DECWRL for hosting the meeting.

As the first item of business, Deering suggested that the group might
wish to elect a new chairperson, because of potential conflict-of-
interest on his part.  (As the designer of one of the candidate
gateway discovery protocols, he might not be sufficiently impartial.)
The attendees chose not to take him up on his suggestion.

We then reviewed the various candidate gateway discovery protocols that
had been identified and discussed on the mailing list:

  stub RIP      - using default-route-only RIP broadcasts to inform
                  hosts of gateway presence; usable by any gateway,
                  not just those using RIP as their IGP.

  cisco GDP     - a UDP-based protocol very similar in functionality
                  to the IS-discovery part of the ISO ES-IS protocol.

  ICMP-D        - Deering's proposed ICMP extensions, based on low-
                  frequency periodic multicasts by gateways (i.e.,
                  not frequent enough for timely detection of gateway
                  failure).

  ES-IS subset  - the gateway-discovery/gateway-failure-detection
                  subset of ISO 9542, with the minimum of changes
                  required to carry IP addresses in IS Hellos.

  Proxy ARP     - eliminating the need for "gateway discovery" by
                  making the gateways invisible.

  PP1           - Prindeville's proposal #1, in which an IP unicast
                  datagram is sent as a LAN multicast packet when
                  no gateway address is known, triggering a Redirect.

  PP2           - Prindeville's proposal #2, in which hosts send ICMP
                  multicast queries to locate gateways.  The proposal
                  was unclear on whether or not queries are for a
                  specific destination/TOS, or for default gateway only.
          [It has since been clarified: the queries are for
          specific destination&TOS.]

  X.Y.Z.1       - using a well-known address (such as address number 1
                  on every subnet) to identify the "current default
                  router".  The routers run an election algorithm to
                  decide which one answers to that address at any time.

  BOOTP         - three popular protocols used to supply hosts with
  Sun BootParam   one or more gateway addresses (along with other info)
  MIT NIP         at boot time.  Might be extended to supply gateway
                  addresses at other times.

The list was then trimmed to three candidates -- RIP, GDP, ICMP-D --
for further discussion.  The others were eliminated for the following
reasons:

  ES-IS - use of ISO packet formats unnecessarily complicates
          implementation on simple IP-only hosts; no "preference
          level" field; political hot-potato.

  Proxy ARP - if hosts don't know they are talking to a gateway, they
          won't obey Redirects; difficult for gateways to decide
          which is "best" choice; "slowest gateway wins" phenomenon.

  PP1   - difficult for gateways to decide which is "best" choice;
          Redirect implosion; duplicate delivery.

  PP2   - incomplete specification; scales poorly with large numbers
          of hosts.

  X.Y.Z.1 - won't work with existing hosts that don't time out ARP
          entries; too late to reserve a special address on all
          subnets.

  BOOTP, BootParam, NIP - not designed for dynamic, on-going discovery
          of gateway addresses; hosts might get confused on receiving
          an unsolicited, partial BOOTP broadcast; beyond charter of
          this group.

We then proceeded to identify the following pros and cons of stub RIP:

  Pro:    - already supported by many hosts and gateways.

  Con:    - uses broadcast rather than multicast.

    - is named "RIP" -- it has become politically incorrect
          to advocate the continued use of RIP.  (Possibly solved
          by giving the stub RIP subset a new name?)

        - no "holding time" field, which is important if doing
          ES-IS-style gateway failure detection.  It means that
          hosts have to have wired-in knowledge of the gateway
          broadcast rate, which would have to be 30 seconds for
          the scheme to work with existing RIP implementations.
          Unfortunately, 30 seconds is too long for reasonable
          dead gateway detection, and much shorter than needed
          for discovery only.

        - [not mentioned at the meeting, but in an earlier mail
          message: danger of stub-RIP broadcasts from non-RIP gateways
          confusing full-RIP gateways on the same wire.]

We also discussed using full RIP packets (i.e., containing per-
destination routes, rather than just default routes) for the sake
of multi-homed hosts, which have to do more than just discover
a default gateway.  By comparing routing metrics reported on
each connected subnet, a multi-homed host can decide which subnet
to use as the first hop towards a given destination.  However,
RIP is less than ideal for this application, because:

    - RIP packets do not carry Autonomous System numbers,
      which would allow hosts to know whether or not RIP
      metrics from different subnets can sensibly be compared.

    - RIP routes are per-destination only, rather than
      per-destination&TOS.

    - The RIP packet encoding for IP routes is very inefficient,
      which means that large routing tables must be split across
      more packets than necessary.

Unlike RIP, the remaining two candidates -- GDP and ICMP-D -- are
amenable to change (no need for backward compatibility).  Therefore,
rather than going through the pros and cons of each protocol, we
identified the differences between the two and agreed on a resolution
of those differences, thus coming up with the "best" of the two.
Those differences are:

  - GDP is a UDP application; ICMP-D is an ICMP extension.
    Resolution: use ICMP.  This is the logical place for this
    functionality in the IP suite.  It was recognized that it is
    generally easier to add UDP applications to an existing
    implementation than to extend ICMP, but that the need for the
    protocol to manipulate the IP default gateway list might be
    more easily met by an ICMP-level implementation in some cases.
    It was noted that, for 4.3bsd Unix and derivatives (e.g., current
    versions of SunOS and Ultrix), the required ICMP extensions can be
    implemented either inside the kernel or in a user-level process.

  - GDP uses broadcast; ICMP-D uses multicast.
    Resolution: specify the use of multicast, but recognize that some
    vendors and network administrators will use broadcast anyway, at
    least until hosts and gateways are upgraded to support multicast.
    Therefore, discourage the use of broadcast but do not forbid it
    ("SHOULD multicast").

  - GDP includes a "holding time" field; ICMP-D does not.
    Resolution: include a holding time field.  This field allows a
    gateway to control how long a host continues to believe that
    the gateway is alive, in the absence of new information; it is
    important if the protocol is to be used for gateway failure
    detection as well as gateway discovery, and is useful in any
    case.  (There is some controversy over how gateway failure
    detection ought to be done and, in order to progress the
    gateway discovery protocol, we are putting off resolution
    of that issue for now.  It is expected that this working group
    will evolve into the "black-hole detection" working group
    after it's initial charter has been satisfied.  Including the
    holding time field in the packet format will leave the options
    open for that future work.)

  - GDP allows more than one gateway address to be reported in a
    single packet; ICMP-D only allows one (the IP source address
    of the packet.
    Resolution: allow more than one gateway address.  This is NOT
    intended to allow one gateway to report other gateways' addresses
    (although it does permit such usage); it is for gateways connected
    to LANs that carry more than one IP subnet, where a gateway may
    have a different address for each subnet.  Hosts receiving the
    gateway reports must pick out only those addresses that belong
    to the same subnet as the host, and ignore the rest.

  - GDP does not carry subnet masks in its gateway reports; ICMP-D does.
    Resolution: do NOT include subnet masks.  This means that,
    before engaging in the gateway discovery protocol, a host must
    know its own mask (as well as its own address).  There are already
    several existing mechanisms for acquiring that information, e.g.,
    static configuration, BOOTP, and ICMP Mask Reply; it is expected
    that the Host Configuration Working Group will standardize on a
    mechanism for obtaining various subnet parameters, of which the
    mask is only one.

  - GDP allows for 2^16 preference levels (priorities); ICMP-D allows
    for only 8 preference levels.
    Resolution: no big deal, but 8 levels should be sufficient.
    However, there is some doubt as to the value of including
    preference levels at all.  The working group does not want to
    specify at this time how hosts shall deal with preference levels,
    but agrees to include the field for private use or possible
    consideration at a later time.

  - GDP does not specify randomization of periodic gateway reports
    (to avoid synchronized transmissions) or any mechanism to
    reduce the traffic during simultaneous boot-up by many hosts;
    ICMP-D specifies both.
    Resolution: specify randomized reporting intervals; the ICMP-D
    mechanism for replying to multiple multicast queries with a single
    multicast reply is to be suggested but not required.

Deering volunteered to revise his draft RFC to reflect these decisions,
to be ready by the February IETF meeting.

Greg Satz generously agreed to let us use his (cisco's) BSD Unix
implementation of GDP as the basis of a freely-distributable
implementation of the revised protocol.  We hope to have that ready
by the February meeting as well.

The next meeting of the Gateway Discovery Working Group will be at the
February IETF meeting in Tallahassee, Florida.  We intend to split
a single afternoon session between us and the MTU Discovery Working
Group, which has many of the same members.